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(54) Generic remote procedure call system 

(57) A system and method allow cfient applications 
to invoke remote procedures on a server application 
using any of a plurality of remote procedure mecha- 
nisms, by selecting a remote procedure call mechanism 
at runtime. The system and method uses client and 
server stubs In the application that include an mecha- 
nism-independent canonical specification of each pro- 
cedure interface. The specification defines the fomi of 
the Interface and arguments, bktt not does include con- 
ventional mechanism-specific marshalling arguments 
for marshalling the arguments. The resulting compiled 
stubs may be used with any remote procedure call 
engine. Such remote procedure call engines receive the 
specification of the procedure interface and the argu- 
ments passed by the client application to the sender, and 
determine at runtime tfie particular marshalling routines 
to use. according to the canonical specification. This 
defers selection of the marshalling routines, and hence 
allows a single conpiled client application binary code 
to be used with any of a variety of remote procedure call 
engines and marshalling routines. Defening selection of 
marshalling routines further allows optimization of data 
types where the client and server conputers share 
architectural characteristics. The system Includes a 
Interface definition language compiler tiiat produce tiie 
client and server stui>s having tiie canonical sp^ifica- 
tion of the procedure interfaces, a virtual remote proce- 
dure library that selects a remote procedure call engine 
fa a client, and plurality of remote procedure call 
engines. 
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Description 
BACKGROUND 

5 Field Of invention 

The present inventions relates to client-server distrilxJted confuting systenis generally, and mere particularty, to 
systems providing multiple remote procedure call mechanisms dynamically selected at runtime to provide dient-server 
interprocess communication aruJ data transfer. 

10 

PacKgroMrKl of Irwention 

Client-server computing has become the predominant model of distributed confuting, paralleling the tncr^sing 
performance of desktop computers and workstations. In a client-server distributed a)nputing environment, multiple 

15 conputers are connected in a networK and a computer may operate both as client, a consumer of resources and data, 
and a server, a producer of resources and data for the clients. Acconrpanying the spread of client-server systems, there 
has been a move away from the homogenous networks common in the past where there was typically a single or very 
few vendors providing all the computers, to heterogeneous networks with computers, software, and peripheral devices 
from nultiple vendors, in this environment, integration of client-server operation becomes a critical requirement 

20 In any client-server environment, a client requests operations of a server through a remote procedure call (RPC). 
In a remote procedure call, a process on a local computer, the client, invokes a process, the server, on a remote com- 
puter. Historically, the kfea was to perform the remote procedure call with a single thread of control hekl by the client, 
so that the RPC behaved in the same manner as a local procedure call. In order to achieve this goal, there must be an 
agreed upon set of semantics between the client and the server for describing the procedure call and specifically, the 

25 arguments passed across the call. This is because both the client and the server may have different internal architec- 
tures for representing data, and thus, explicit specification of types of arguments is used to communicate data between 
the client and server. In addition, becai^e the client and sender typically are different computers, each with its own 
address space, passing parameters by reference is not usually possible. Conversion and construction of data for trans- 
mission between the client and server is called marshalling. In a general purpose RPC mechanism explicit typing is 

30 necessary, since implicit typing cannot be used unless a single RPC mechanism is chosen. In a heterogeneous envi- 
ronment, there may be multiple RPC mechanisms in use. and thus, explicit typing is needed. However, marshalling rou- 
tines are specific to each RPC mechanism, since they designed to construct the data for a particular and machine 
architecture RPC mechanism. 

In conventional RPC systems, the dient holds an interface to the sender in the form of a client stub. The sery/er has 

35 a server stub that provides the linkage to the server application. These stubs are created by the application developer 
by using the interface definition language (IDL) to specify tiie interface, and tiien compiled by an IDL conrpiler. The IDL 
is used to specify ttie int^face between tiie client and the sender. The dient-server interface is conventionally defined 
as a set of procedures witii specifically defined input and ojtput arguments. 

In conventional systems, the sennantics of each remote procedure call are implemented when the stubs are com- 

40 piled by the IDL cOTipiler. The IDL conpiler determines the specific marshalling routines for use the arguments in a 
given procedure, and links tiiese routines into the object code of the interface. The stub is tiien compiled into the appli- 
cation binary. The resulting, executable binary application code thus, can only be used with the particular RPC mecha- 
nism that uses the linked-in marshalling routines. At runtime, tiiere Is no ability to select which RPC mechanism to use 
when several are available, since tiie marshalling routines are already part of the application. 

45 In a homogenous computing environment where there is a single RPC mechanism, this approach was acceptable. 
The selection of a single RPC mechanism ensured that all applicatiois were developed to use just tiiat mechanism. 
However, honK)genous systems are no longer tiie typical environment. Rather now heta-ogwieous systenre are com- 
monplace where a single RPC mechanism becomes a limitation on tiie interoperability of clients and servers. Ideally 
then, a client application shoukf be able to use the sendees of any server, regardless of the RPC mechanism. That is, 

60 where multiple RPC mechanisms are available on the system, the client should be able to select an RPC medmnism 
when the server is invoked. 

With conventional RPC mechanisms, this is not possible because ccmventional RPC systems are incompatible and 
have inconpatilsle APIs. While the individual RPC, mechanisms in and of themsdves support heterogeneous environ- 
ments for different machine architectures, dients and senders do not support heterogeneous operating environments 
55 for different RPC mechanisms. More specifically, there are numerous distinct interface definitions languages, each witii 
its own semantics, and witii distinct conpilers. Each IDL compler is exclusively tied to distinct RPC mechanism, and 
each RPC mechanism has its own particular set of marshalling routines for servers using tiie RPC mechanism. Mar- 
shalling routines of cne RPC system cannot t>e used witii another. Thus, existing applications that are com^led for use 
witii a specific RPC mechanism cannot be used with other RPC mechanism. This pr^ent an application selecting an 
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RPC mechanism at runtime. 

To make the application interoperable with other RPC mechanism conventionally requires rewriting the interface of 
the server in the specific IDL of the new RPC, and then modifying and recompiling the application with the marshalling 
routine of the RPC. This process is expensive and time consuming, and results in the user having to choose which 
5 application to execute depereling on which RPC mechanism is desired. The selection of RPC mechanisms is confusing 
to the user and inefficient 

Accordingly, it is desiral)le to use a mechanism that isolates the interface definition of the client-server interface 
from the RPC mechanism and marshalling routines, so that the RPC mechanism can be dynamically selected when the 
client is about to use the RPC mechanism on the server. Since the selection is performed at runtime, the client and 
10 server can select the RPC mechanism that best suits the operating environment on a per invocation basis. This allows 
the selection of RPC mechanism to be made at runtime, rattier than at compile time, resulting in the desired heteroge- 
neous system flexibility. Deferring selection of marshalling routines to invocation also makes clients and server nrore 
portable between hardware platforms and operating systems and allows the addition of new RPC mechanism to an 
installed base without change to such mechanism. 

75 

SUMMARY OF THE INVENTION 

In one of its aspects, the present invention overcomes the limitations of conventional RPC systems by aeating a 
canonical specification of a procedure interface at ttie time that ttie client or server stub is compiled. When the client 

20 stub is subsequentiy invoked to initiate tiie remote procedure call, this canonical specification is passed to a selected 
RPC engine which in turn detennines how to marshall tiie arguments used in the interface and invoke tiie call. Only 
when the RPC engine is selected are ttie marshalling and invocation routines determined. Interpreting the canonical 
specification at runtime allows for ttie most optimal implementation of the specification, rather ttian fixing any form of 
the implementation at compile time. TTie resulting implementations from the invention, because tiiey derive directiy from 

25 the canonical specification, they will offer higher performance than implementations derived from predetermined set of 
marshalling and invocation routines. 

With ttie interpreted canonical specification, RPC engine marshalls ttie interface arguments frf and when neces- 
sary) and transmits them to ttie server by invoking the server stub. The sender stub tiien unmarshalls data, interprets 
the canonical interface specification to determine ttie actual arguments and data types, executes ttie call, and returns 

30 the result arguments. 

This process provides a Virtual" remote procedure call ("VRPC") system. The remote procedure call is Virtual" 
because the client stub does not have ttie specific implementation ttiat marshalls the argument at ttie time of ttie call. 
The virtual remote procedure call system separates out tiie semantics of tiie procedure call, which are inportant to tfie 
RPC mechanism, from ttie syntax, which is important to ttie application developer. In addition, because ttie determina- 
35 tion of RPC engine and ttie selection of marshalling routines is delayed until runtime, the canonical specification may 
be optimized where ttie client and server computers are of tiie same architecture, by using opaque data types rather 
than marshalling into machine independent representations. This optimization further improves the performance of ttie 
RPC mechanism. 

In one aspect of the invention, the canonical specification is created by an interface definitional language compiler 

40 when the stubs are generated. The canonical specif ication describes ttie number of arguments, the data type arKl at 
least one argument mode in a machine independent manner. In one embodiment, ttie specification of data type is pro- 
vided using an agreed set of bytecodes that define ttie representation fonnat of ttie canonical specification. Complex 
data types are specified recursively The actual data values for the interface arguments are not included in ttie canonical 
specification, but determined at runtime. The use of bytecodes enables the VRPC system to be independent of specific 

45 RPC mechanisms since ttie bytecodes define the argument datatypes independently of ttie machine architecture on 
which an arbitrary RPC mechanism is implemented. For exanple, a bytecode specifying an integer datatype may 
define it to be precisely two bytes in length. In contrast, in conventional programming languages, such as C, the pro- 
grammer can define a variable to be an integer, but cannot specify ttiat all integers are two bytes. Rather, ttie computer 
on which the program is compiled has its own internal format for storing the data and stores ttie integer in that prede- 

50 termined format, and ttiat storage format may be different from ottier integer formats on ottier computer architectures, 
even for ttie exact same program. Wrth the bytecode specification of the present invention, regardless of how the client 
or sender computer internally def ine an integer, it is stored in the same memory format. 

Anottier aspect of the present invention is a virtual remote procedure call library and a nuntjer of virtual remote pro- 
cedure call mechanisms, or VRPC backends. " Each VRPC backend con-esponds to a specific RPC system and 

55 includes a virtual remote procedure call engine ttiat performs ttiat actual transfer of data across ttie networic. and a set 
of marshalling routines. The VRPC library facilitates communication between a client stub and a server, ard enak)les 
the selection of VRPC backend by a client stub. 

Because ttie selection of RPC mechanisms is defen-ed until runtime, the use of ttie VRPC system on a given client 
machine can be used to select any availattle RPC mechanism without ttie need for the VRPC system to be present on 
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other server machines on the netwjrk. This provides various advantages, such as aflowing any arbitrary RPC nr»^- 
nism to work whh the VRPC system, and thus allowing the client program to use any RPC mechanism without ipgrad- 
ing the server or recompiling the dient program. In addition, the VRPC system allows individuals client machines to be 
upgraded over time, without requiring all clients on a network to use the VRPC system. This reduces the cost and diffi- 
cutty of migrating a large network to the VRPC system. 

In another aspect of the invention, the use of canonical specifications enables the generation of wire-conpatible 
protocols with existing and unmodrfied RPC servers of various types. Fifftiiermore, existing interface definition lan- 
guage compilers can be modified to produce VRPC stubs without requiring any change in the underlying programming 
language. In addition, existing network and RPC-spedf ic libraries may 1:^ used to guarantee RPC protocol compatflsility. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is an illustration of a dient-server distn*buted confuting system in accordance with the present invention 
Figure 2 is a data flow diagram of the process of generating client and server stubs. 
Figure 3a is an illustration of a type hierarchy for the interface specification. 
Figure 3b is an illustration of the send call invocation of a VRPC engine. 

Figures 4a and 4b are an event trace and data flow diagram of the process of invoking a VRPC engine. 
DETAILED DESCRIPTION OF THE INVENTION 
gyst^m ArchltpptMrg 

Referring now to Figure 1. there is shown one embodiment of the virtual remote procedure call system of the 
present invention in a dient-server distributed computing system. The VRPC system 100 is a distributed dient-server 
system capable of operating wrth heterogeneous machine architectures. System 100 indudes client conputers 110 
(one client computer 110 is illustrated), coupled to server computers 160 through a network 150. The dient computers 
110 may be conventional personal computers or workstations, such as Sun Microsystems Inc. SPARCstations. Intel- 
based x86 computers. IBM 390 or 400 series microcomputers, or the like. In the preferred embodiment, the cWetit and 
server computers use Sun Microsystems' Solaris 2.x operating system, including the Open Network Computing Plus 
{ONC+) networking environment. 

The client computers 1 1 0 provide both an application development and execution environment for developing appli- 
cation programs in accordance with the present invention. The application development environment 112 indudes 
application programming tools such a code editor, a source code compile, a linker, a syntax checker, and the like. In 
accordance with the present invention, an IDL compiler 1 1 4 is also provKled. The IDL compiler 1 1 4 generates client and 
server stubs that are independent of €iny rpc mechanism. More particularly, a dient stub has no dependendes on inter- 
face or network services that defines the marshalling of the input and outjfHit arguments of the dient stub. 

Rather, the client stub 1 20 and server stub 1 64 both include a canonical specif k^tion of their Interfaces. The canon- 
ical specification defines in a machine and RPC-independent manner the data structures and interlace routines for the 
client and server interfaces. The canonical specification uses explicit typing of data structures and interface routines. In 
the preferred embodiment, the expiidt typing is provkled by a bytecode specification that is understood by a variety of 
VRPC backends 140 and marshalling routines 142. The canonical specification is machine readable and can be exe- 
cuted by any VRPC engine 1 44 to communicate a data stream containing the arguments and data types of the interface 
between the client and server for a given remote procedure call. A type dictionary 123 created by the IDL compiler 114 
and provided in the client 1 1 6 and server applications 1 61 stores the spedf k; types used in the dient and server Mx. 

The bytecode specification in the client and sender stubs are conventionally compiled with main af^lication source 
code routines to generate dient applicaticKis 1 1 6 and server applications 1 61 . As compiled, stubs are executable by the 
application in a normal manner since the stubs have the appropriate syntax for int^cing with their applications. 

In the execution environment there is provided in the client 1 1 0 and server 1 60 computers a VRPC library 1 22. and 
a plurality of VRPC backends 140. The VRPC library 122 provides the communication linkage between the Indivkiual 
client stubs 120 and the server stubs 164 and one of the VRPC backends 140. The VRPC IS)rary 122 indudes various 
routines that are invoked by either the dient stub or server stub, as necessary to select a VRPC backend 1 40 and estab- 
lish a connection therebetween. TTie routines dynamically select an available VRPC backend 140, passing to it the 
canonical representation of the int^ce and the data used by the stub. The selection process is determined at runtime, 
rather than during compilation of the stubs, as is done conventionally The VRPC library 122 indudes a service provkler 
interface for the VRPC backends 140. so that any VRPC backend 140 can be sut)stituted for any other. 

Each VRPC backend 140 indudes a VRPC engine 144 and marshalling routines 146. The VRPC engine 144 
receives the canonical specification of the interface provided in the dient 120 or server stub 1 64, along with harKHes to 
the data being passed, and calls the aj^ropriate marshalling routines 142 to format the data structures ar^l int^lace 
routines according to the bytecode specification in the canonical specification, passing the data values to the marshal- 
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ling routine 142 since the marshading routines 142 on the client share the same address space. The bytecode specifi- 
cation only defines the data structures of tfie interfiace, rt does not specify how these are to be nrtarshalled. Rather, each 
VRPC engine 1 44 Is responsible for determining which marshalling routines 1 42 are used. In a preferred embodiment, 
there are multiple different VRPC backends 140. each specific to a single rpc mechanism, such as ONC-RPC sup- 

5 ported by Sun Microsystems, or OCE-RPC, or tfie like. 

The marshalling routines 142 marshall and unrmrshall the passed in arguments, and return them to the VRPC 
engine 144. These routines are dynamically detennined ard invoked at runtime, rather than linked into the application 
binary itself. In this manner, the VRPC engine 144 is selected only when the client is invoked, not when the client stub 
120 is generated by the IDL compiler 1 14 as in conventional systems. 

10 A naming service 190 provides name to address translation for server applications 161 on the network 150. Each 
sender application 1 61 on the network 1 50 has an address, maintained in the naming service 1 90. and optionally includ- 
ing a specification of which VRPC backend 1 40 is to be used with the server 1 61 . The server applications 1 61 are pref- 
erably responsible for registering themselves with the naming sendee 190. The naming service 190 provides the name 
or address of a server in response to requ^ts from other entities, such as the VRPC library 122 or client application 

15 116. 

Because the selection of VRPC engine 144 and marshalling routines 142 is deferred until runtime, any number of 
different VRPC engines 144 and marshalling routines 142 can be used with the same client 1 16 and server stubs 161 , 
without having to recompile the stubs and application for the new rpc mechanism. This allows a single application 
binary to be distrikxjted and be known to be compatible with cunent or future rpc mechanisms available on the network, 
20 thereby eliminating the cost and difficulty of converting each application to each specific rpc mechanism. 

System Qpgratlon 

Generation of Client and Server Stubs 

25 

Referring now to Figure 2. there is shown a data flow diagram of the process of generating client 120 and server 
stubs 164. For the purposes of tills disclosure, tine present invention is described with respect to a development and 
execution of a single client stub 1 20 for a single application. Application to the general case will be understood by those 
of skill in the art. 

30 The application developer, using the application development environment 1 12 produces a client application 116 
and server application 161 generally as follows. Ttie developer writes a dient code 206 and server procedure code 202 
in a conventional manner. 

The developer further writes an interface specification for the client and server applications in an IDL language 
compatible with tiie IDL compiler. The interface specification defines a set d functions or procedures of tiie client and 

35 server, along witii their input arxl output arguments. In accordance with the Invention the, IDL compiler 1 1 4 is independ- 
ent of the RPC mechanism, and so any IDL language compler is acceptable. Suitable IDL languages includes 
DCE/RPC IDL, Microsoft's MIDU CORBA IDL. Sun Microsystems ONC-RPC IDL In Figure 2. the interface specifica- 
tion file is illustrated generally by the f9e fbo.x (204). 

The IDL compiler 114 oonpiles the IDL specif cation file to produce a client stub 120. here foo_client.c and sepa- 

40 rately a server stub 164, foo.server.c. The stubs are source code files in a target source language and provide tiie 
source code level interfaces for the client ar^ server. 

More particularly, the IDL compiler 1 14 provides three functions. First, it parses a client-server interface specifica- 
tion described in the input IDL file. The typical IDL language is similar to procedural programming languages, but gen- 
eral provides only structure declarations, function prototypes, and constant expressions. In the preferred entoodiment, 

45 the IDL conrpiler 114 may include a number of different front end parsers, each one adapted for handling a different 
interface definition language. 

Second, the IDL compiler 114 generates programming language specific bindings for tiie interface specification. 
This involve mapping parsed interface definitions to tiie specific programming language and operating system con- 
straints of tiie execution environment. Tiie language binding of an IDL describes how a particular function or data struc- 

50 ture is translated from the IDL language to the target programming language. The output of the IDL compiler 1 14 is a 
source file providing a specification of tiie interface in a form that can be compiled witii, and executed by tiie client and 
sender applications. The preferred target source languages are C and C++. 

Rnally, tiie IDL compiler 1 14 generates the actual dient and server sti& code for tiie language bindings that per- 
forms the actual renxite procedure calls. Unlike conventional IDL compilers 1 14 tiiat produce stii) code that indudes 

55 calls to specific marshalling routines for marshalling tiie data staK:tures of the interface, the stubs produced by the IDL 
compiler 1 1 4 do not spedfy tiie marshalling routines to be used for passing ttie input and output arguments. Ratiier, tiie 
stubs include the canonical specification of the data structures being passed between tiie dient and ttie server. The 
canonical representation is maintained in a first data structure, an interface definition st'ucture. The interface definition 
structure provides an abstract description of the format of tiie interface, including the data types of the number of input 
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and output arguments, their rrumber, and an identification of the remote procedura The ^ecification of ^e data types 
is provided by a bytecode; each of the VRPC engines 144 is capable of Interpreting the bytecodes and determining the 
proper marshalling routines. A separate data structure or set of data structures is used to point to the argument values 
themselves. 

5 The IDL compiler 1 14 further includes in the client stubs 120 calls to the VRPC library 122 and an abstract VRPC 
engine 144. These calls pass the interface specification to the VRPC library 122 and VRPC engine 144. Rather, the 
VRPC library 122 calls a selected VRPC engine 144 in one of the VRPC backercls 140, to interpret or conpile the 
implementation of the client interface, and the VRPC engine 144 performs the transformation of the specification into 
its implementation using its associated marshalling routines. The IDL compiler 1 14 also includes in a header file for the 

10 client stub 1 20 calls to establish and terminate a connection with the server 161. 

The IDL compiler 1 14 further produces in the client stub 1 20 and the server stub 164 a type dictionary 123 that con- 
tains all of the data types used in the interlace definition. Each data type in the type dictionary 123 is a defined by a 
series of bytecode sequences. This allows complex data types in the procedure interface to be represented by refer- 
ences to entries in the type dictionary 123. On the server side, the type dictionary 123 is used by the server stub 164 

15 to reconstruct the data types of the raw data received during the remote procedure call. 

Figure 3a illustrates the type hierarchy of a preferred embodiment of the interface specification 324. The interface 
specif icatton 324 is illustrated abstractly as an argument to an invocation of a send method of a VRPC engine 1 44. This 
invocation is used by the client stub 120 to invoke a selected VRPC engine 144 to make the actual remote procedure 
call to the server 1 61 . In this enrt)odiment, the int^ce specification 304 includes a description of the remote procedure 

20 interface and a description of the arguments to be supplied to the renKSte procedure. The description of the remote pro- 
cedure interface includes: 

an identifier 326 for a procedure number of the particular function procedure. A server interface will typically ir^lude 
a number of procedure calls available from the server. The IDL compiler 114 assigns each of these a unique iden- 
25 tif ier 326 so that the client and server can reliably exchange information about a specific procedure; 

a variable 328 specifying the type of the return argument value for the remote procedure. This allows the remote 
procedure to determine the proper marshalling routine for the return value before sending it to the client; and, 
a variable 330 specifying the number of arguments between passed in the procedure call. 

30 Appendix A includes an exemplary implementation of the type hierarchy of Figure 3a In that embodiment, the inter- 
face specification 324 is provided in the VRPCj3roc_spec_t structure definition. 

In the prefen-ed embodiment the canonical description of the arguments is an argument specification 332 that 
includes a set of elements that describe each argument. The actual values of the arguments are not included in the 
argument specification 332, but only their form. For each argument, there is an argument type 336, and at least one 
35 argument mode 334. An argument mode 334 specifies the semantics for handling the arguments between the client 
and server. Generally, the modes define whether an argument is an input or output argument. In the prefenred embod- 
iment, the modes are refined to handle different types of relationships and optimization between the client and server. 
In a lend " mode, the argument is provided to tiie sender 1 61 . which modifies it and returns the modified value back to 
the client 120. In a lend to" mode, the server 161 receives a copy of the argument and may use that value during the 
40 invocation of the remote procedure, and subsequentiy deallocates memory for that use. The client must still maintain 
the argument locally In a "copy to" mode, a copy of the argument is sent to the server 161 , which mi^t free its copy 
upon completion. In a "copy from " mode, the dient 116 does not send data to the server 161 , but rather receives data 
having the defined data type. In a "move to" nxxle, the argument held by ttie client 1 16 is deleted after being sent to 
the server 161, and the server 1 61 frees tiiis copy after use. Finally, in a "move from ' mode, the server 1 61 passes data 
45 to the client 1 1 6 and deleted by the server, and the client 1 1 6 frees this instance after use. 

An argument type 336 specifies data type for the argument(s). The data type is provided by a bytecode value. The 
bytecode is used to specify both primitive types, such as ints, chars, and ttie like, and n^re complex types ttiat are 
recursively defined. Appendix A, Section 3.4 includes an exemplary list of bytecodes for representing primitive, pointer, 
and conposed (complex) data types. Other bytecode specifications may also be used. These bytecodes are recog- 
50 nized by the VRPC engines 144, and used by the VRPC engines to select marshalling routines to marshall the argu- 
ments into the proper representation for transmission to the server, and then reconstruction by the server. 

In the prefen-ed embodiment, the argument specification structure 332 is included in the procedure interface spec- 
ification 324, however, in alternate embodiment, the argument specification structure 332 may be separated from the 
procedure interface specification. Rgure 3a illustrates this relationship. Appendix A provides an exenrf^ary implemen- 
ts tation of tiie argument specification 332, in the VRPC_args_6pec_t structure. 

Because the selection of marshalling routines according to the data types of the arguments is delayed until the 
actual invocation of the server interface, the bytecode specification may be optimized on a per-connection basis to take 
advantage of the architecture of tiie dient and server computers. Mae particularly, if both the client and server comput- 
ers are of the same architecture, such as tx)th Sun Microsystems SPARCstations, then selected data type specific 
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opcodes can be replaced with opaque data types, theretsy eliminating the need to nmrshail the data into a machine 
Independ&tt format For example, if the data type spedfied by an qxode is a dout^e, it may t>e replaced by eight 
opaque bytes of data, tt is significantly more efficient to transmit the eight opaque bytes than to convert a double into 
an machine independent representation, such as XDR (see below) and then convert back from the machine independ- 
5 ent representation to the double. This optimization may be performed by the VRPC engine 144 that is selected at runt- 
ime. 

As illustrated in Rgure 3a. tiie interface specification including the argument specification, are passed to an VRPC 
engine 144 by invoking its send method. When invoked, the VRPC engine 144 traverses tiie argument specification 
332. and determines from tiie bytecode specification of the argument types 336 the appropriate marshalling routines. 

10 The VRPC engine 144 also separately receives tfie actual argument values 338. The VRPC engine 144 then calls the 
marshalling routines to marshall the arguments for trar^ission to the server 161. This process is further descdbed 
below with respect to Figure 4. The client stub 1 20 furttier passes to tiie VRPC engine 1 44 a state description 380 (Rg- 
ure 3) defining tiie transport parameters for the remote procedure call, and ottier information, such as tiie version 
number 381 of VRPC engine, the name 385 of the VRPC engine, flags 383 for controlling the backend. a handle to the 

15 State data 387. and a handle 389 to a destructor function for freeing tiiis state information. An exemplary implementa- 
tion of tiie VRPC state desaiption is provided in Apperdix A. §4.1. 

A simplified example of a client stub 120 created by an IDL compiler 1 14 illustrating tiie canonical form of tiie inter- 
face definition is as follows. Assume that the client stub is to contain a function for summing two variables. A and B. In 
the lOL file foo.x this function is represented as: 

20 

intsum(inta. intb); 

The IDL compiler 1 14 creates a canonical specification of tiiis interface In the client stub in the file citent.c: 

25 1.# include "VRPC.h" 

2. int sum VRPC_state *be(int a. int b) { 

3. int tmp; 

4. void *arg_addr[3]; 

5. arg_acfclr[0] = &a; 
30 6. arg_addrllj = &b; 

7. argLaddr[2] = &tmp 

8. be->send(VRPC_state. inter_descr, arg_addr) 

9. return(tmp); 

10. } 

35 

Line 2 defines the interface to the client stub seen by the client a^lication. The interface is consistent with the 
application's interlace as defined in the IDL ffle. This allows the application to invoke tiie dient stub without the applica- 
tions developer having to provkled any f urtiier interlaces between the application and the stub. Tlie body of the stub is 
hkiden from tiie application, arxi the application has no information that the sum procedure is being remotely handled. 

40 Line 1 specifies the header ffle wNdi includes the calls for establishing and terminating a connection with a VRPC 
engine 144. The header file is further described below. 

Line 3 defines the output variable, tmp. This allows the dient to have a local handle to a variable for returning the 
result from the remote procedure to tiie application. Line 4 defines an array arg_addr that is sized to contain pointers 
to the two input and one output arguments. In tiie general case, the argument array contains a pointer for each ir^ut 

45 and output argument. More generally, in tiie preferred embodiment, the dient stub receives all arguments as pass by 
reference, including arrays and non-arrays. The argument array correspcKids to tiie argument list 338 in Figure 3a. 

Lines 5 tiirough 7 define ttie contents of the ara^addr array, witti pointers to tiie passed in variables a and b, aruJ 
a pointer to the output variable tmp. In tiie prefened en^xx^iment. the dient stub accepts all arguments as pass by ref- 
erence, whether these are array or non-anay arguments. This arguments array will be passed to one of the VRPC 

50 engines and selected marshalling routine. Since tiiese components all reside in the same address space as ttie client 
stub, they will be able to access the data values of the argument as need when tiie data structures of the interface are 
marshalled at runtime. 

Line 8 performs the refr%)te procedure call itself. This call corresponds to the server interface 302 in Rgure 3a. The 
canonical specification of ttie interface is provided as an input argument inter_descr to the send.call function, with 
55 interjdescr being an interface specification 324. &e is a function points to one of the VRPC engines, any of which pro- 
vide a serKi.cali function. The send.call function passes down tiie interface specification 324. interjdescr, which here 
contains a description of the sum function. The send.call further passes the data that accompanies the interface defi- 
nition, the arg^addr array. When tiie remote procedure call is completed, the result will be in the tenporary variable 
tmp. As shown in Figure 3a. ttie remote procedure call has a return type 340 that indicates whether the remote proce- 
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dure call was succes^l or whether there was an error. 

For this example of the function sumQ. the simplified version of the interface specification 324 would be: 

^ Struct ( 

int proc_no = 1; 
int n_args = 3; 

struct arg_spec args (2]={(IN, int_bytecode) 
(IN, int^bytecode), 
,5 (OUT, int.bytecode)}; 

I inter.descr; 

where arg^spec is a structure that implements the argument specification described above. The mode values of IN" 

20 and X)il " are merely illustrative here, and other argument mode values may be used, as described above. Exemplary 
mode values are described in Appendix A, §3.2. in the VRPC j)aram_mode_t structure definition. The procedure 
number, return type. type, and number arguments are determined by the IDL compiler 114. 

As noted above, the interface specification 324 does not contain any of the data being passed between the client 
and server, but merely the form of that data. Because the data are not included in the canonical representation, this rep- 

25 resentation can be provided to any VRPC engine 1 44 for marshalling. Only when the marshalling at runtime is actually 
performed is the data accessed from the arguments an'ay 

The client stub described here is a simplified representation of the interface of the client. Rgure 3b illustrates an 
abstract representation of the interface for this invocation. In a preferred emlxxliment. the invocation 340 of the VRPC 
library 122 passes in a data structure, here called optab_baseJ 353, that encapsulates both the interface specification 

30 and argument specification, and an argument list In addition, the VRPC library 122 receives arguments specifying tiie 
version 350 for the client stub 120, flags 352 for setting witches in tine library if necessary, the size 354 of the encap- 
sulating structure, for use in marshalling the arguments, a handle 358 to tiie type dictionary used for tiie interface, and 
handles to call the VRPC engine 144 directly for state information (360). its send method 362. and its control metiiod 
364. The control method 364 is a general function which tiie VRPC library 122 uses to instruct the VRPC backend 140 

35 to perform additional functionality. For exanple, the control method 364 may be used to instruct a VRPC backend 140 
to select the security level for a connection between the client and server. 

In addition, a set of function pointers 368 to the client stub 120 are also provided for main routine 118 to call. The 
VRPC engine 144 also receives tiie argument list 338 witii the actual arguments references for tiie VRPC engine 144 
to marshall. The VRPC engine 144 returns a value 340 indicating whether the renrxite procedure was successful, or 

40 whether an error resulted. 

When the client application 1 1 6 first connects with tiie server, tiie client invokes the VRPC library 1 22 to establish 
a connection and select a VRPC engine 144. The VRPC library 122 initializes the be handle with the address for a 
selected VRPC engine 144, and cli^ stub function pointers to interface routines. Accordingly, when ^e client stub 120 
is subsequentiy invoked, it is provided a handle to tiie VRPC engine 144 which can then marshall the data structures 

45 of the interface according to the interface specification structure. The selection process for choosing a VRPC «igine 
144 at runtime is further descrit)ed below. The client 116 invokes the VRPC library 122 using interfaces provided in a 
header file incorporated in all client stut^s 120. 

The VRPC library 122 provides two basic functions to tiie clients: initiation/termination of a connection between cli- 
ent/s^er and selection of a VRPC engine 144. The interfaces to ttiese functions are provided to a client stub 120 in 

50 the VRPC header file 209. More particularly, there is a function to establish a connection to the server using a selected 
VRPC engine 144. This function takes as an \npuX the name of a server to be conducted, generally provided on ttie 
server computer 1 60, and a handle to the client/server interface being accessed. This function invokes tiie VRPC library 
1 22 on the client computer 1 1 0. which obtains from naming service 1 90 the name and address of a server 161 including 
a VRPC engine 144 sp^ied for use by the server application 161 having tiie server interface. The VRPC library 122 

55 then initializes state variable handle be for contacting the server using that VRPC engine 144. Otherwise, the VRPC 
library 122 returns a error value. The VRPC library 122 returns the handle to the VRPC backend 140 to tiie client stub 
1 20. An exemplary interface for this function is VRPC_begin() function described in Apper^lix A, §1 .1 . Note that the csUI 
to VRPC.beginQ takes an optab.basej 353 as an argument, thereby providing to the VRPC librEiry 122 ttie handle to 
the interface specification and the argument specification in the client sub 1 16. 
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A complementary function terminates a remc^e procedure call connection thrcHigh the VRPC engine 1 44 specified 
the handle chained from iratiation function. Th^ function Is called by the ai^llcatlon 1 66 at the end of its execution. An 
exemplary interface is shown in Appendix A. §1 .1 as VRPC.erKlO- 

Exenplary Implementations of the VRPC library 122 functions are illustrated in Appendix A. §1.1. 

5 

Execution of Clients and Selection of a VRPC Mechanism 

Referring new to Figure 4a arKi 4b ^ere is s^rawn an event trace and data flow diagram of the process of exec^ng 
a remote procedure call In accc^ance with the present invention. The dtent application 1 16 containing the remote pro- 

10 cedure call is executed on a client compute 1 1 0 In a conventional manner. The application 116 inclides a call to initial- 
ize the handle in the client stub 120 to the VRPC backend 140 used to invoke the backend's send.call method. The 
application 1 16 invokes 400 this initialisation method, for exanple VRPC.beginQ. on the VRPC library 122. passing in 
an identification of a server Interface being accessed. The VRPC lit^ary 122 is responsible determining the VRPC 
engine 144 to be used and establishing a connection to the server application 161 using the VRPC engine 144. The 

15 VRPC library 1 22 queries 402 the naming service 1 90 for the server address and name of the VRPC backend 1 40, The 
naming service 190 returns 404 the address of the server 161 and the name of the VRPC backend 140, which the 
VRPC library 1 22 then uses to select the VRPC engine 144. Generally the selection of the VRPC engine 144 Is based 
on the address of the server or the backend name before the connection to the server is established. The address, or 
the name retrieved from the naming service 190 identifies the specific RPC mechanism to use, and the library 122 

20 knows how to interpret the address from the nan^ng service 190. The client 116 then connects 406 to the server 161 
by calling the VRPC library 122, which then establishes the connection to the server 161 with the selected VRPC 
engine 144 on the client computer 1 10. and con^espondingly with a VRPC engine 144 on the server conputer 160. For 
example, If the address Indicates an ONC-RPC mechanism, the library 122 will k>ad in the ONC-RPC backend, and so 
on. As a consequence of connection being established, the VRPC engine 1 44 Is loaded by the client computer 1 1 0. The 

25 VRPC library 1 22 will obtain a handle to the VRPC engine 1 44 once the VRPC engine 1 44 is loaded. The VRPC library 
122 returns 407 this handle to the client stub 120 so that future Invocations of sendjcall will be made directiy on the 
selected VRPC engine144. 

At some sut>sequent point, the main routine 1 18 Invokes 409 the dient stub 120 by calling one of the procedures 
defined therein, and passing in some number of arguments. The client stub 120 packages the actual arguments and 

30 the argument spedf ication to create the procedure call, specifying the argument mode(s) and type of eadi argument, 
and the procedure description, specifying the procedure number, number of arguments, return type. The dient stub 120 
then Invokes 408 the sendjcatt method. This call is forwarded by the VRPC library 122 to the selected VRPC engine 
1 44 on the client computer 1 1 0. 

The VRPC engine's 144 on.the dient computer 110 interprets the Interface specification to determine the form of 

35 each argument, induding its nKXje(s) and data type according to the bytecode specification. The interpretation further 
determines from the procedure number the appropriate p-ocedure to invoke on the server 161 . From this information, 
the client's VRPC engine 144 selects the appropriate marshalling routines from the client computer 110 marshalling 
library 1 22 for marshalling the arguments into a form that can be transmitted across the network to the server applica- 
tion 161 . The VRPC engine 144 invokes 410 these marshalling routines as needed to create the proper representatic»i 

40 of an input data structure. Each marshalling routine returns 412 a transport spedf Ic data representation for the input 
data structure. The invocation of the marshalling routines is specific to the VRPC engine 1 44. In one embodiment based 
on Sun Microsystems ONC-RPC. the marshalling routines use the data representation specified in XDR: External Data 
R^resentatlon Standard RFC 1104. June 1987. In this environment, the VRPC engine 144 invokes a function 
clnLcallQ of the ONC-RPC mechanism that performs the dient side of the remote procedure call for any application: 

45 

clnt_call(procedure number, 

*datastruct, *XDRfun, 
*datastruct, *XDRfun)) 



This marshalling call spedfies the procedure number for the procedure being serviced, and provides |:K>int6rs to 
55 data structures and the marshalling and unn^halling functions. 

Where the dient computer 1 1 0 and the server computer 1 60 are of the same architecture, the client VRPC engine 
144 may qstimize the bytecodes by using opaque data types, rather than marshaliir^ with the marshalling routines. 

The VRPC ^gine 144 on the dient conputer 110 then serxJs 414 the marshalled data and arguments to the 
instance of the VRPC engine 144 on the sender computer 160. The VRPC engine 144 on the s&rwer contputer 160 
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unrarshalls 416 the arouments using the marshalling library 122 on the server computer 160. Referring to Rgure 4B. 
the marshalling library 122 reUims 41 7 original interface specif 'ration to the sender's VRPC engine 144. 

The VRPC engine 144 on the server oomputer 160 interprets 418 the interface specif ication. using its type diction- 
ary 123, which con-esponds to the type dictionary used by the client skile VRPC engine 144. This allows the server's 

5 VRPC engine 144 to recor^truct the spedftc data structures of the original arguments, along with identifying the spe- 
cific procedure to be invoked in the server application. The VRPC engine 144 passes 419 the arguments in the fc»^m 
spedfied by the interface specification, and procedure number to the server application 161 . The server 161 executes 
420 the remote procedure on these arguments to obtain the desired result. The server 161 returns 421 the result to the 
server VRPC engine 144. The server VRPC engine 144 again marshalls 422, 424 the result according to the interface 

10 specif toation, and sends 426 the marshalled data back to the client VRPC engine 144, The client VRPC engine 144 
unmarshalls 428, 430 the data with the client marshalling library 122. and fonwards 432 the return arguments to the cli- 
ent stub 120. which passes the result to the client application 1 16. 



25 



30 



35 



IS 




Sun Microsystems, Inc. Proprietary information. 
Copyright © 1995 Sun Microsystems, Inc. 



45 



SO 



55 



10 



EP0 784 268 A2 



Table of Contents 



1 VRPC Client Interface 1 

1.1 Client Initiation i 

1.2 Client Stub API 2 

10 2 VRPC Server Interface 3 

2.1 Server Initiation 3 

3 Interface Specification Mechanism 4 

3.1 Virtual Data Representation 4 

3.2 VDR Internals 4 

3.3 Type Dictionary 6 

3.4 VDR Bytecode (Type System) 7 

3.4.1 Canonical Types 7 

20 3.4.2 Pointer Types 8 

3.4.3 Composed and Meta Types 9 

4 VRPC Backend Interface 10 

4,1 Interface 10 

^ 4.2 Backend Support Routines 11 

4.3 ONC/RPC Opcodes 12 

4.4 Membuf Opcodes 12 

Functions Index 14 

30 

Data Types Index 15 

Concepts Index 16 

35 



40 



45 



SO 



55 



11 



EP0784 268A2 



Chapter 1: VRPC Client Interface 1 

1 VRPC Client Interface 

1«1 Client Initiation 

These functions are declared in the following header file: 
#include <vrpc/vrpc.h> 

void * vrpc-begin (const char *name, const void Function 
*clatJ)ps) 
Establish VRPC connection. 

name is used to query a naming system to identify and locate the 
server process. 

clntjops identifies the interface being accessed. It is the address of a 
app/.optab.t as found in the compiler generated file *appJ.vclnt . c'. 
vrpc.beginO returns a pointer to an initialized appi_optab,t, or nil 
on error. 

int vrpc-end (void *opsp) Function 
Terminate a VRPC connection initiated by vrpc.baginO. 

opsp is a pointer previously obtained &om vrpc.beginO. 

vrpc.endO returns 0 on success and -1 on error. 

int vrpc-begin^buf (const char «name, const void-* " F\inction 
•ctntjopSf void *opsp, size.t ops^z) 
EsUblish VRPC connection. 

name is used to query a naming system to identify and locate the 
server process. 

clntjops identifies the interface being accessed. It is the address of a 
appJ.optab.t as found in the compiler generated file *appLvclnt,c*, 

ops is the address of an appLoptab.t to be initialized. Its size is 
passed as the next argument. Its size mxist match the object pointed 
to by clntjops, 

ops-sz is the size of the structure pointed to by opsp. 
vrpc.begin.buf 0 returns 0 on success and -1 on error. 

int vrpcend-buf (void *opsp) Function 
Terminate a VRPC connection initiated by vrpc.begin,buf (). 
opsp is the address of a structtxre previously initialized by vrpc.begin. 
bufO. 

vrpc.end.buf 0 returns 0 on success and -1 on error. 
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Chapter 1: VRPC Client Interface 2 

1.2 Client Stub API 

For each remote function defined in the IDL. a client stub routine is 
generated. Calling this stub function causes the appropriate server function 
to be invoked with the same arguments; the result of the server routine is 
returned by the client stub routine. 

int opsp'> method (appLoptab.t *opsp^ args, . .) Function 
Malce an RFC call. In^^kes function method as defined in the IDL. 
opsp is a pointer to an appi.optab.t as initialized by vrpc.begin. 
buf 0 (see Chapter 1 (Client API), page 1). 

args are the actual RPC arguments. Note that the VRPC client stub 
routines all accept arguments as pass-by-reference arguments. All non 
array arguments are passed by reference. Arrays are also passed by 
reference, but no additional translation is performed since C already 
passes arrays by reference. 

Also note that return function values are passed back in the last ar- 
gument of the argument list. In other words, the function value is 
converted to a piass-by-reference variable. 
methodO returns 0 on success and -I on error. 

Each *appLvclnt.c' file contains an interface definition. The definition 
is of type appi_optab_t and is conventionally placed in a variable called 
AFPL.optab. 

appi^ptab.t Data type 

typ«d«f fitmct { 

optab.ba8«.t bas«; 

iftt (•f uac) (appLoptab.t 

coast fiue.urg «, iat •fuac.res); 

} appLopt^b.t; 

base is of type optab.base.t as described below (see Section 3.2 [VDR 
Internals], page 4). 

f unc each appi.optab.t has one or more members which are function 
pointers. These are initialized by the compiler generated code to client 
stubs which perform the corresponding RFC. 

The appi,optab_t has function pointers to the client stubs. Each 
of these client stubs calls the be_s6nd.call routine for that appJ. 
optab.t with the appropriate arguments. One of these arguments is 
a vrpc_proc.spec_t. 

This page under construction. 
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Chapter 2: VRPC Server Interface 3 

2 VRPC Server Interface 

2.1 Server Initiation 

These functions are declared in the following header file: 
♦include <vrpc/vrpc - b> 

void * vrpc-begin (const char ^name^ const void Function 
♦ctat-ops) 
Establish VRPC connection. 

name is used to query a naming system to identify and locate the 
server process. 

clntjops identifies the interface being accessed. It is the address of a 
appi.optab.t as found in the compiler generated file 'appi.vclnt .c*. 
vzpc.beginO returns a pointer to an initialized app/.optab.t, or nil 
on error. 

This page under construction. 
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Chapter 3: Interface Specification Mechanism 



4 



3 Interface Specification Mechanism 



3,1 Virtual Data Representation 

VRPC uses a Virtual Data Representation scheme to describe application 
data structures and procedures. Simply put, data structures and procedures 
defined in an IDL axe translated into a specification language which is ma- 
chine readable. This language consists of specific opcodes (see Section 3.4.1 
[bytecodel], page 7) much like a common assembly language. 

Since the specification is machine readable, these opcodes can be executed 
by a VRPC backend to properly communicate a data stream between the 
cUent and server for a remote procedure call. 

Additionally, specific optimizers can be invoked on a per-connection basis 
to optimize the b3rte-code in a way suitable for the archltecturaJ character- 
istics of the client and server machines. 

For example, if the peer machines are of the same architecture (eg. 
SPARC), then the optimizer can replace most data type specific opcodes 
in the VDR with opaque data types. For example, a double can be re- 
placed with 8 opaque bytes. It is significantly more efficient to communiate 
8 opaque bytes than to convert a double into (for example) XDR and then 
do the translation from the common format back to a double. 



3.2 VDR Internals 



optab.base.t 



Data type 



typedof stroet { 



nuigaod long 
Quaigned los^ 
«iz«.t 

const ctiar 

coast TTpc.tdict.t 

▼rpc.be.ops.t 

Int 



.▼•rsion; 

.flags; 

.size; 

«ii«a(a; 

•vdr.tdict; 

•b.bo.handlo ; 

(«b.8oad.e&lI) (vrpe.be.ops.t * , 



coast TTpc.proc.spsc.t *. 



lat 

} opt&b.bas«_t; 



void *apa}; 
(«b.ctrl) (optab.base.t lat, void •) 



.version is the version number (1). 
.flags option flags (0). 

.size is the size of the encapsulating appi.optab.t. 
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Chapter 3: Interface Specification Mechanism 5 

name is the string name of the interface described by the encapsulating 
appi.optab_t. 

vdp.tdict is a pointer to the VRPC type dictionary for this interface 
(see Section 3.3 [typedict], page 6). 

b.be.handle is a VRPC backend handle, 
b.send.call backend routine that makes RFC call, 
b.ctrl backend control routine. 

vrpc-proc-spec-t Data type 

typedef stmct ( 

oasigacd long opaujn; 

ttasiS&ed long rtjpe.id; 

oaiig&ed long nargs; 

co&ft vipc.arg8.8p«c.t •args; 

> vrpc.proc.sptc.t; 

opnum the procedure ntunber or unique identifier for this procedure 
within the scope of this interfece. 

rtype.id the type ID of the return value of this function, or 0 if the 
return type is void. 

nargs the number of arguments this function takes. Also the number 

of entries in the args array. 

args an array of nargs vrpc_args_spec.ts. 

vrpc-args-spec-t Data type 

t7|»«d«f stmct { 

Trpc.paraffljBoda.t mod* ; 

tusi^ted long typv.id: 

> vrpc.args.8p«c.t; 

mode The parameter passing mode, 
type.id The type ID of the argument. 

vrpc_parani_mode_t Data type 

PM.LEHD.TO, 
PIf.COPT.TO, 
PM_COPT.FR0K, 
PK,HOVE.TO, 
PH.HOirE.FaON 
} 7rpc_paraa.jBod«.t; 
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Chapter 3: Interface Specification Mechanism 



6 



PH.LEND The argument is sent to the server, where it is modified, and 
the modified value is copied back to the client. In a shared memory 
implementation, this may be implemented as pass-by-reference. 

PM,LEND_TO A copy of the argument is sent to the server. The VRPC 
runtime, frees the server's copy of the arguments when the RPC in- 
vocation has completed on the server. The client side instance is not 
freed. 

PM_C0PY_TO A copy of the argument is sent to the ser\'er. The server 
side application code must free its copy. The client side instance is not 
affected. 

PM.COPY^FROM No data is sent from the client to the server, but data 
is returned from the server to the client. The server side instance is 
not freed. The client must free the copy it receives. 

PM^MOVE.TO Client side instance is deleted after call. Server side must 
free instance. In shared memory implementation, the object is not 
freed, however, responsibility for freeing object moves from client to 
server. 

PM.HOVE.FROM Server side instance is deleted after call. Client side 
must free instance. In shared memory implementation, the object is 
not freed, however,responsibility for freeing the object moves from the 
server to client. 

3.3 Type Dictionary 

Each 'appi.vdr.c' file contains a dictionary of the types represented in 
that file. The dictionary is of type vrpc_tdict_t and is conventionally 
called APPL.typetab. 

The dictionary is simply an array of pinters to opcode sequences. Each 
of these opcode sequences defines a data type of the interface. When data 
types are nested, the referene to the nested data t3rpe takes the form of an 
index into the type dictionary. 

vrpc.tdict_t Data type 

t7p«d«f strnct { 



> vrpc.tdict.t ; 

nctypes Number of type entries in ctype 

ctype Each array entry points to a sequence of vrpc.opcode.ts. Each 
of these sequences describes a data type used in this VRPC interface 
specification. 




iLctyp«8 ; 
•cozut •ctype; 
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Chapter 3: Interface Specification Mechanism 

3.4 VDR Bytecode (Type System) 

Each VRPC backend implements a subset of the following opcodes: 

3.4.1 Canonical Types 

VRPC_bool32 ofiset 

a 32 bit boolean. 

VRPC.byte offset 

opaque byte. 

VRPC.intS offset 

8 bit char 

VRPC,intl6 offset 

16 bit short 

VRPC_int32 offset 

32 bit long 

VRPC.int64 offset 

64 bit long 

VRPC.uintS o&et 

8 bit unsigned char 

VRPC.uintie offset 

16 bit unsigned short 

VRPC_uint32 offset 

32 bit unsigned long 

VRPC.uiat64 offset 

64 bit unsigned long . 

VRPC.enumS offset 

an 8 bit enum (eg. C++ support) 

VRPC.en\mil6 offset 

a 16 bit mum 

VRPC.enTim32 offset 

a 32 bit enum 

VRPC.enTim64 oiBet 

a 64 bit enum 

VRPCf loat32 offset 

a 32 bit float 

VRPC_float64 offset . 

a 64 bit float 
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Chapter 3: Interface Specification Mechanism 8 

VRPC.f loatl28 offset 

a 128 bit float 

VRPC.charS offset 

an 8 bit character 

VRPC.charie offset 

an 16 bit character 

VRPC,char32 oifeet 

an 32 bit character 

VRPC.zcharS ofiset 

an 8 bit zero terminated character 

VRPC.zcharie ofket 

an 16 bit zero terminated character 

VRPC.zchar32 offset 

an 32 bit zero terminated character 



3.4.2 Pointer Types 

Each of these items describes the type of a pointer. The offset is that of 
the pointer value. 

VRPC.stringS offset 

a AO* terminated string of 8 bit chars 

VRPC.stringl6 offset 

a string of 16 bit chars 

VRPC,string32 offset 

a string of 32 bit chars 

VRPC.stringSM max-ien offset 

a AO' terminated string of 8 bit chars 

max-len defines length to malloc for string, excluding AO* terminator 

VRPC.stringl6N max-ien offset 

a string of 16 bit chars 

VRPC_string32M max-/en offset 

a string of 32 bit chars 

VRPC.pointerl ptr-offset type-instr 

pointer to 1 instance of tj77e-instr 

VRPCpointerN n-count ptr-offset type-instr 

pointer to n-count instances of type-instr 
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Chapter 3: Interface Specification Mechanism 9 

5 VRPC.pointerL len-instr val'OfFset type-instr 

pointer to L instances of type-instr 
VRPC.pointerML £nax*count len-instr val-ofEset type-instr 
pointer to len-instrO instances in buf of size max-count 

10 VRPC.appl 

a pointer to an upcall routine 

3.4.3 Composed and Met a Types 

15 

VRPC.nop 
do nothing. 

VRPCnest type-id offset 
a reference to another type 

20 

VRPC.vector count type-instr 

fixed sized array of length count of type type-instr 

VRPC.array 

an array 

25 

VRPC.struct struct'Size struct-name 
a struct 
VRPC,estruct 
end of a struct 

30 

VRPC.SunlonC union^ize union-oSset disc^ixistr ncsses default-type-td 
(case, type-id) 
union-in-struct with cases 
VRPC_RTerror 
^ force runtime error 
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Chapter 4: VRPC Backend Interface lo 

4 VRPC Backend Interface 



4.1 Interface 

A VRPC backend is expected to export the following interface. The 
backend must be implemented as a shared library that the VRPC library 
can dlopenO. 

The shared library must have an entry point (function) which uses its 
arguments to construct and return a pointer to a vrpc.be.ops.t. 

vrpc_be^ops_t * vrpccreatcADDR (const Function 
vrpc.tdict.t *ty, const void «addr*info) 
ADDR is the actual name assigned to the particular VRPC backend. 

ry is the application's type dictionary (see Section 3.3 [typedict], 
page 6). 

addr-info is some backend specific address information. This informa- 
tion may be used to connect to the RFC server. 

vrpc.create.ADDHO returns the address of an initialized vrpc.be. 
op8_t or oil on error. 

Note that the destructor for this data type is called using a funciton 
pointer within the data type. 

• vrpc_be_ops-t Datatype 

typedef struct { 

onais&ed loag .ba.vcrsioa; 
ojuigued long .be.flags; 
const char •b^.aftma; 
rrpc.bs.state.t «b«.dat4; 

Toid («btt.imtr«nsport) (vrpc.bs.stste.t •) ; 

> vTpc_b«_op».t ; 

This type is used to hold state information for a VRPC backend. 

bd . flags is used to hold state flags. 

be. version is used to indicate the backend version, 
be .name holds the name of the backend. 

be.data is used by the backend to store a pointer to its own private 
state information. 

bd.untransport points to a destructor function for be.data. When 
it is non nil. it is called by the VRPC nmtime with be.data as an 
argument when the vrpc.be_ops_t is destroyed. 
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4.2 Backend Support Routines 

const op » peekJnt (const op ♦ip, const void •dp, Panction 
unsigned long «res) 
This function returns an integer &om memory. It is typically used 
to determine the dimension of dynamically sized arrays and discrimi- 
nators in unions. The instruction sequence must consist of canonical 
types. 

ip points to the instruction sequence describing the type of integer to 
read. 

dp points to the user's data structure (integer). 
res points to where the read integer is returned. 
peek.intO returns the value of the advanced ip. 

const op * pokeJnt (const op *ip» const void *dp« Function 
const unsigned long *va/) 
Thb function writes an integer to memory. It is typically used to 
set the dimension of dynamically sized arrays and discriminators in 
unions. The instruction sequence must consist of canonical types. 

ip points to the instruction sequence describing the type of integer Co 
write. 

dp points to the user's data structure (integer). 

vai points to the integer value to be written to memrory. 

poke.intO returns the value of the advanced ip. 

size.t size-at (const op ^const *tdict, const op *ip} Function 
This function returns the size of an object described in VDR. 
tdict points to the type dictionary to be used, 
ip points to the instruction sequence describing the object. 
size.atO returns the size of the object in bytes. 

const op * skipl-at (const op »ip) Function 
This function advances the instruction pointer to the next VDR in- 
struction. 

ip points to the instruction sequence to be skipped. 
skipi.atO returns the value of the advanced ip. 

const op « has-pointer (const op vconst ^tdict. Function 
const op *ip, int •res) 
This function examines the pointed to object and decides whether the 
described object contains any pointers, 
tdict is the type dictionary. 
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jp is the address of the VDR description of the object to be examined. 

res points to an int where this function returns its value. It is set to 
TRUE if a pointer is found, and FALSE if no pointers are found. 

has.pointerO returns the value of the advanced ip. 

4.3 ONC/RPC Opcodes 

The following opcodes are implemented by the ONC/RPC backend mod- 
ule. 

VRPCJlTerror 

VRPC^unionC 

VRPCJ)00l32 

VRPCbyte 

VRPC-enum32 

VRPCjBstruct 

VRPC-float{32,64,128} 

VRPC-nest 

VRPCaiop 

VRPCpointerML 

VRPCpointerN 

VRPC-stringS 

VRPCjstringSM 

VRPC^truct 

VRPC-vector 

VRPC.{,u}int{8,16,32> 

4.4 Membuf Opcodes 

The following opcodes are implemented by the Membuf backend module. 
Note that the Solaris/Doors backend is built on top of the membuf backend. 

VRPCJCTerror 

VRPCJunionC 

VRPCJ)0ol32 

VRPCbyte 

VRPCjenumi: 

VRPCjestruct 

VRPCJoat{32,64,128} 
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VRPC-nest 

VRPCjiop 

VRPC-pointerML 

VRPCpoiiiTtirN 

VRPCjstringS 

VRPC^tringSM 

VRPC-Struct 

VRPC-vector 

VRPC-{,u>int{8a6,32} 



Functions Index 

Functions Index 



H 
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O 

opsp*>method 2 



peekant H 

pokaoAt 11 



s 
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V 

vrpcbegxa 

vxpcbegin^buf 
vrpc.creat«-.ADDA 

vrpcend 

vrpc.endJ»uf 



Data Types Index 

Data Types Index 



A V 

appi-optab.t.... 2 vrpc-args-spect 

vrpc^a^ps.t 

vrpc .par anu&ede .t 

Q vrpc-proc jpec-t 

optab.basa.t 4 



vrpc-tdict-t . 
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Claims 



1 . An interlace definition language conpiler. for use with a conputer system providing at least one mechanism-inde- 
pendent remote procedure call system for execution of a procedure in a server, the procedure invoked by a client 
and taking zero or more arguments, wherein the Interface definition language compiler receives an interface defi- 
nition file including a declaration of the interface of the procedure, and converts it to an mechanism-independent 
canonical specification including an identification of the procedure in the server, and for each argument included in 
the interface, a specification of a data type of the argument and at least one argument mode for passing the argu- 
ment and defining tiie semantics for using the argument In the procedure, the compiler producing a client stub 
including the canonical specification, the dient stub adapted to be conpiled into the client for execution thereby. 

2. The interface definition language conpiler of claim 1 , wherein the interface definition lanaguage compiler produces 
a server stub adapted to receive the canonical specification of the interface of the procedure, and determine there- 
from for each argument a data type and at least one argument rtKXle for the argument for providing tiie arguments 
to the server procedure, and for returning an output argument to tiie client stubi 

3. The interface definition language compiler of daim 1 , wherein the argument modes indude an input mode and an 
output mode. 

4. The interface definition language compiler of daim 1 . wherein the argument modes indude a lend mode and a lend 
to mode. 

5. The interface definition language compiler of claim 1 , wherein the argument modes include a wove to mode and a 
move from mode. 

6. The interface definition language compiler of daim 1 . wherein the argument modes indude a copy to mode and a 
copy from mode. 

7. The interface definition language compiler of claim 1 , wherein the canonical specification includes an interface 
specification comprising: 

a specification of a procedure identifier that uniquely identifies the procedure in the server; 
a specification of the number of arguments; and, 

a specification of a return type for the output argument of the server procedure. 
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8. The interface definrton language compiler of daim 7, wherein the canonical specification includes an argument 
specification identifying for each of the nunr^er of arguments at least one argument mode, and the data type of the 
argument. 

9. The interface definition language compiler of claim 8. wherein the data type of each argument is specified by a byte- 
code representation. 

10. The interface definition language compiler of daim 9. wherein: 

the interface definition language compiler produces a type dictionary including an entry for each unique data 
type, the entry induding bytecode representation spedfying the data type; and, 

the argument specification includes for the data type of each argument a reference to an entry in the type 
dictionary. 

1 1 . The interface definitic^ language compiler of daim 1 operating with a computer system comprising: 

a plurality of marshalling routines; 

a client renxste procedure call engine and a s&ver remote procedure engine, the rennote procedure engines 
providing a transport mechanism between the client stub and a server stub of tiie server procedure; and. 

wherein tiie interface definition language compiler produces in the dient stub an invocation to tiie dient 
remote procedure call engine to provide thereto the canonical specification, the dient remote procedure call engine 
adapted to invoke selected marshalling routines according to the data types of the arguments specified in the 
canonical specification to marshall values for the arguments into transport spedf ic structures, the dient remote pro- 
cedure call engine further adapted to provide the transport spedfic structures to tiie server remote procedure 
engine which invokes selected marshalling routines to otstain tiie argument value and data types, and provides tiie 
argument values and data types to tiie server stub. 

1 2. A computer system for executing in a server application a remote procedure call by a client application, comprising: 

a client side computer including: 

a client application including a client stub to the remote procedure, the client stub receiving zero or more 
arguments from the client application, and having an invocation that passes the canonical spedf ication to 
a dient remote procedure call engine, the canonical specification of ttie interface of the remote procedure 
including: 

a procedure identifier uniquely identifying the remote procedure in a server interface of a server; 
for any argument specified in the interface of the remote procedure an implementation and machine 
indeperKlent argument specification of a data type of the argument, and at least one argument mode 
for passing the argument and defining tiie semantics for using the argument in the procedure; and. 
a set of references, each reference for obtaining a value to an argument; 

a first plurality of marshalling routines, each mars^lling routine assodated with specific dient remote 
procedure call engine, and adapted to rrmrshall an argument value by constructing for tiie argument 
value a representation of argument value tiiat is specific to tiie dient remote procedure call engine and 
determined by tiie data type of ttie argument; 

at least one client remote procedure call engine, each client remote procedure call engine capable of 
receiving the canonical specification, and determining from the argument specification of the data type 
of each argument at tiie time the renwte procedure call is executed, each client remote procedure call 
engine slapted to invoke for each argument in the canonical specification at least one nrmrshalling 
routine associated with the client remote procedure call engine to marshall the argument, tiie dient 
remote procedure call engine invoking the marshalling routine only at a time when the client remote 
procedure call engine is invoked by dient stub, and ttie client remote procedure call engine deter- 
mined at substantially a same time as when the client application is executed. 

13. The conputer system of daim 12. further comprising: 

a server side corrputer induding: 

a server application indiding tiie remote procedure; 
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a server stub prcvkjing the tnterface to the rermite procedure; 

a second plurality of marshalling routines, each marshalling routine associated with specific server remote 
procedure call engine to be Invoked thereby, and adapted to unmarshall an argument to determine its 
argument value and data type; 

at least one seiver remote procedure call engine adapted to receive from a dient ren^te procedure call 
engine eac^ marshalled argument, the serv^ remote procedure call engine invoking at least one marshal- 
ling roitine of the second plurality to unmarshall the argument to determine the argument data type and 
argument value, the server remote procedure call engine providing the argument value and data type of 
each argument to the server stii>. 

14. The system of daim 13. further conr^rislng: 

an interface definition language compiler that produces from the interface of the server procedure the dient 
stub and server stub. 

15. The system of daim 14, further comprising: 

a type dictionary i nduding an entry for each unique data type in each canonical spedf ication of the server inter- 
faces, a byteoode representation, and the canonical specification of the serv^ interfaces includes for the argu- 
ment type of each argument a reference to an entry in the type dictionary. 

1 6. A computer inrptemented method of creating an application stub for compilation into an application, the application 
stub interfadng the application to a remote procedure call mechanism for executing a procedure call defined in the 
application stub, the method comprising: 

receiving an interface definition of the procedure, the interface definition including zero or more input or output 
arguments; 

converting the interface definition to a canonical specif ication of tiie interface by: 
specifying an identification of the procedure in the server; 

specifying for each argument Induded in the interface a data type of the argument and at least one argu- 
ment mode of the argument; 

and, 

providing the canonical specification in the application stub. 

17. The method of claim 16, further comprising: 

providing in the application stub an invocation of a dient remote procedure call engine, the invocation passing 
to tiie client rerTK)te procedure call engine the canonical specif Iction. 

18. The method of claim 16, further comprising: 

creating a server Gidb to receive the arguments specified in the application stub, and provide the arguments to 
a server application including tiie server procedure. 

19. The method of claim 16, further comprising: 

creating a type dictionary that indudes an entry for each unique data type in the canonical specification, the 
entry induding a bytecode representation of the data type, such that tiie cam)nlcal specification indudes for 
the data type of each argument a reference to an enfy in tiie type dictionary 

20. The method of claim 1 9. wherein the type didionary is provided to both a dient application induding tiie dient stub, 
and a server application including the server procedure. 

21 . In a computer system including a dient computer and a server conputer, a computer readable memory for tiie cli- 
ent computer configured to provide a r^ote procedure call between the client conputer and the server corrput^, 
comprising: 
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a di^ appiicat'cKi including a dient stid) to the remote procedure. 

the dient stub receiving zero or more arguments from the dient application, and having an invocation that 
passes the canonical specification to a dient remote procedure call engine, the canonical specification of the 
interface of the remote procedure including: 

a procedure identifier uniquely identifying the remote procedure in a server interface of a server; 
for any argument specified in the interface of tiie remote procedure an implementation and machine irxle- 
pendent argument specification of a data type of the argument, and at least one argument n^e for pass- 
ing the argument and defining the semantics for using the argument in the procedure; and, 
a set of pointers, each pdnter for obtaining a value to an argument; 

a first plurality of marshalling routines, each marshalling routine associated with spedf ic dient remote pro- 
cedure call engine, and adapted to marshall an argument value by constructing for the argument value a 
representation of argument value that is ^ecrf ic to tiie dient remote procedure call engine and determined 
by the data type of the argument; 

at least one client renx>te procedure call engine, each dient remote procedure call engine capable of 
receiving the canonical specification, and detenmining from the argument specification of tiie data type of 
each argument at ttie time the remote procedure call executed, each dient remote procedure call engine 
adapted to invoke for each argument in the canonical specification at least one marshalling routine asso- 
ciated with the client remote procedure call engine to marshall the argument, the client remote procedure 
call engine invoking tiie marshalling routine only at a time when the client remote procedure call engine is 
invoked by dient stub, and the dient remote procedure call engine determined at substantially a same time 
as when the dient application is executed. 

22. The computer readable memory of claim 21 . furtiier comprising: 

an interface definition language conpiler that produces from tiie interface of tiie server procedure the dient 
stub. 

23. The conputer readable memory of claim 21. further comprising: 

a type dictionary induding an entry for each unique data type in each canonical specification of the server inter- 
faces, a bytecode representation, and tiie canonical spedf ication of the server interfaces includes for the argu- 
ment type of each argument a reference to an entry in tiie type didionary. 

24. In a computer system induding a dient computer providing a dient application and server computer providing a 
server procedure, a computer implemented method of providing a remote procedure call from tiie client application 
to the server procedure, comprising: 

invoking the server procedure through an server interface in a dient stub in tiie client application, and providing 
to tiie server procedure a nun^er of arguments; 

invoking a remote procedure call engine, and providing thereto a canonical specification of tiie server interface, 
tiie canonical specification descnl)ing for each of ttie nuni}er of arguments, a data type of the argument and 
at least one argument nxxje for passing the argument arKi defining the semantics for using the argument in the 
server procedure; 

marshalling each of the arguments according to its data type with marshalling routines selected by the remote 
procedure call engine; and, 

providing tiie marshalled arguments to tiie server procedure. 

25. The method of claim 24, further comprising: 

selecting the remote procedure call engine at substantially a same time as the invocation of the server proce- 
dure from among a plurality of remote procedure call engines according to a designation of a remote procedure 
call engine associated witii the server procedure. 

26. The method of claim 24, further comprising: 

determining whettier ttie server computer and tiie dient compute have a common architecture; 
selecting arguments from tiie invocation arxl providing opaque data types for the arguments instead of mar- 
shalling the argument with selected marshalling routine; and, 
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retum^type vrpc_engine->send(vrpc state, interface specification, argumentsK-^302 

— vrpc state description -^3 80 

— backend version-^38 1 

— backend flags-^s 8 5 

— backend name-^SSS 

— state inf ormation-^s 8 7 

I — destructor function-^S 8 9 

— interface specification ~-324 

— procedure number-^326 

— procedure return type^'S 2 8 

— number of arguments 3 0 

' — argument specification~'3 3 2 




argument raode~'3 3 4 
argument type-^sse 



' — retum^type 



-340 




error 



success 



FIGURE 3a 
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return type vrpc_backend->method(optab_base_t, argument list) 4 o 

- optab.base_t~-353 
vrpc_base-"^51 

— version -^--350 

— flags -^362 
si2e~^354 
name -^35 6 

— type dictionary handle -^3 5 8 

— vxpc backend handle 6 0 
vrpc backend send method handle'^362 

' — vrpc backend control method-^3 6 4 
■ — >1 client stub function pointers -^3 6 8 

— argument Jist-^S 3 8 
— i retum_type~-34 0 

success 
error 
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FIGURE 3b 



33 



EP0 784 268 A2 



o 



CO 

c 
6 

CO 



cu 



to I 

3 I 
Ol 




u 
a; 
c 
c 
o 
u 



o 

CM 

CO 
w 

c 
a; 



vol 



o 



•a 
c 

CO 

X 
c 

CO 

CO 



c 
o 

1 

•a 

CO 



c 
o 
a 
^ - 

B 

3) 



o 



34 



EP0784 268A2 




35 



